• Resolves: Allow resizing of the columns in the "users" view #43777

Summary

The accounts list columns have a fixed width since the Nextcloud 28 table rework (#39050): before that the columns were fluid and grew with the available space, since then long values (display names, emails, LDAP account names, translated quota strings, storage paths) are always ellipsised, with no way to see or copy them from the list. As an admin of an LDAP-backed server this bites me regularly: the internal account names are UUIDs and I cannot see or copy them (see also #54072).

This PR adds a resize handle to each column header:

• drag to resize (mouse/touch, RTL aware)
• arrow keys as keyboard alternative (the handle is focusable, role="separator" with an aria-label)
• double click to reset the column to its default width
• widths are clamped to sane bounds, applied through per-column CSS variables on the list container so header, rows and footer always stay aligned, and persisted in localStorage

Screenshots

Before	After (account name column widened)

How to test

1. Go to Settings → Accounts (ideally with accounts having long display names / account names / emails)
2. Hover the end of a column header: a resize handle appears
3. Drag it (or focus it and use the arrow keys) to resize the column
4. Reload the page: the width is remembered
5. Double click the handle: the column is back to its default width

Notes for reviewers (draft)

• Compiled assets are intentionally not included while in draft; I will add them (or ask for /compile) once the approach is settled.
• Open questions where I'd like design/team input:
  • persistence: should the widths go to the server side user preferences like the show/hide column toggles (/settings/users/preferences/*, ConfigLexicon), or is localStorage fine here given that pixel widths are display dependent (a width that fits an external monitor may not fit a laptop)?
  • handle affordance: currently a 2px accent line shown on hover/focus — happy to adjust to design guidelines
  • I think a permanent subtle column separator on every resizable column (like the existing one after the display name column) would make the resize handles discoverable; should I add it?
  • anything more needed on the a11y side (e.g. aria-valuenow on the separator)?

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI